Overview

This PR fixes rendering Markdown tables (GitHub-flavoured Markdown syntax) by introducing a new browser-based rendering approach based on an Eclipse-internal SWT web browser and HTML code created by converting Markdown to HTML using commonmark.

The new rendering approach is encapsulated in a BrowserConversationWidget. It only covers conversations in the chat view. The other SWT widgets in the chat view stay unchanged, i.e. the input field, send button, toolbar, etc. The existing copilot conversation rendering is kept working and is still active by default. A new preference allows switching between both approaches. The currently used rendering approach was extracted to StyledTextConversationWidget. Both classes implement the new common interface IConversationWidget. After extensive review and testing, I'd suggest eventually removing StyledTextConversationWidget and the corresponding new preference for switching between the StyledText-based rendering and the new browser-based rendering.

The BrowserConversationWidget renders HTML DIV code blocks representing existing SWT widgets like user / copilot turns, copilot replies, thinking, tool calls, tool confirmation UI, etc. Instead of re-rendering the whole conversation including long copilot turn HTML blocks, the BrowserConversationWidget only inserts new or modifies existing HTML code blocks / attributes to efficiently update the rendered HTML, e.g. while copilot is streaming a reply or thinking text. The look in the BrowserConversationWidget is made very similar to the existing StyledText-based chat view implementation, i.e. it uses the same colors (but in separate CSS files since the e4 CSS files could not be re-used directly), same interaction features and behavior, e.g. automatically collapses a thinking block as soon as thinking finishes, etc. The JavaScript code in the HTML rendering template is kept very simple, the domain knowledge is kept in Java code.

Switching between both rendering approaches can be done using a new Copilot preference:

Interaction between BrowserConversationWidget and the JavaScript code in the web browser:

+--------------------------------------------------+        +--------------------------------------+
| Java: BrowserConversationJavaJsBridge            |        | Browser (chat-view.html)             |
| (driven by BrowserConversationWidget)            |        |                                      |
|                                                  |        |                                      |
| Generic DOM block API:                           |        |                                      |
|   insertBlock(parent, html)                      | -----> | window.insertBlock(p, html):bool     |
|   insertBlockBefore(p, h, b, onResult)           | -----> | window.insertBlockBefore(p,h,b):bool |
|   replaceBlock(id, html)                         | -----> | window.replaceBlock(id, html)        |
|   removeBlock(id) / removeBlockIfPresent(id)     | -----> | window.removeBlock(id)               |
|   setDarkTheme(boolean)                          | -----> | window.setTheme('dark'|'light')      |
|   scrollToBottom()                               | -----> | window.forceScrollToBottom()         |
|                                                  |        |                                      |
|   collapseThinkingBlock / updateThinkingBodyText | -----> | (run JS scripts to update DOM parts) |
|   / updateThinkingBlockTitle                     |        |                                      |
|                                                  |        |                                      |
| JavaCallbacks (interface implemented by the      |        | triggered by user actions / JS:      |
| widget; registered by the bridge):               |        |                                      |
|   copyToClipboard(text)                          | <----- | code-block copy button               |
|   insertAtCursor(text)                           | <----- | insert-at-cursor button              |
|   acceptToolAction(index)                        | <----- | tool confirmation: accept            |
|   dismissToolAction()                            | <----- | tool confirmation: dismiss           |
|   copilotAction(action, param)                   | <----- | quota / job-list buttons             |
|   copilotLogError(message)                       | <----- | JS diagnostics -> Eclipse log        |
+--------------------------------------------------+        +--------------------------------------+

This PR includes a few additional fixes. I extracted them into separate commits in order to make reviews easier. Tests are also added in separate commits.

Testing and comparing the rendering approaches

For convenience while testing (in a separate git branch, not part of this PR), I also added a new target definition file and launch configs for running the Eclipse IDE with all bundles necessary for testing the two rendering approaches with and without themes support.

• Set target-2025-09.target as active target platform, first
• Then choose one of
  • launch/Copilot4e with Themes.launch
  • launch/Copilot4e without Themes.launch
  • launch/Copilot4e (compare chat view rendering approaches).launch for side-by-side comparison (otherwise, i.e. without the com.microsoft.copilot.eclipse.ui.test bundle, the corresponding menu entry is not available, details below)

I added a Copilot menu entry for opening the two rendering alternatives side by side for visual comparison (only available in com.microsoft.copilot.eclipse.ui.test bundle).

Most elements visible in a conversation widget (user turns, copilot turns, tool calls, thinking, sub-agent calls, etc. in various statuses) are rendered here with both rendering approaches side by side using some artificial data. You can switch between dark and light theme, too. This way, you can easily check if the conversation details are rendered in the browser-based widget as you would expect them to be rendered.

Major design decisions

• commonmark-java: Parse Markdown source code and render HTML code with commonmark-java.
  • Well-maintained, extensible library that is available as a plug-in dependency.
  • Thanks to extensions offers support for GFM tables, strikethrough, task lists (in contrast to Mylyn WikiText)
• Web browser widget: Convert Markdown to HTML (with some JavaScript) and render it in a browser widget.
  • Replacement for StyledText-based widgets that don't allow rendering tables in grid layout with proper borders
  • The browser allows proper HTML rendering and JavaScript execution for interactive parts
  • For performance reasons, a single heavy-weight browser widget displays the complete copilot chat conversation
• Keep both rendering approaches, minimize risk: both conversation rendering approaches are kept usable
  • A switch in the preferences allows activating the browser-based rendering. The StyledText-based renderer is the default.
  • Only the conversation rendering is done in the browser widget, all other SWT widgets stay unchanged.
  • Common logic is extracted, e.g. for accessing avatar icon and user name, in order to avoid code duplication.
• Leave domain knowledge in Java: HTML and JavaScript code are kept minimal and simple, conversation handling is done in Java
  • HTML and JavaScript code are kept generic, only simple HTML block insertion, update, and removal
  • Analysis, debugging, refactoring can still be done as usual for Java developers (incl. compiler and static analyses)
  • A single bridge / seam for Java <--> JavaScript interaction for better maintainability and testing
• Tiny incremental DOM updates: Small HTML code blocks are appended / replaced / removed step-wise
  • Instead of re-rendering the whole conversation on each received copilot response chunk we only add, update, or remove
    small HTML DIV code blocks for e.g. reply, thinking, or tool call text blocks or update a few HTML attributes,
    e.g. to update a tool call status
  • This way rendering streamed copilot responses stays performant, smooth, without observable slow-downs
• Separate CSS files for both rendering approaches: Introduce CSS files for the browser widget, besides the e4 CSS files
  • Eclipse e4 CSS files reference SWT widgets that are not available in the browser-based rendering.
  • We could not import color definitions from e4 CSS files
  • Instead, we introduced separate CSS files for the HTML rendering, but re-used the same colors for dark and light theme, where applicable.

Performance

I didn't compare the rendering performance of both approaches, but I implemented the browser-based rendering in such a way that only tiny DOM manipulations are needed during conversation widget content updates (e.g. adding single words while copilot is in thinking state). While testing with exemplary requests to copilot I didn't see any observable slow-downs.

Suggested follow-up tasks for separate PRs

• Fix order of restored conversation blocks: When streaming a copilot answer the blocks, i.e. reply text, tool calls, sub-agent calls, thinking text, may appear in arbitrary order. When loading a conversation from history, these blocks are loaded in a certain order that does not necessarily comply with the original (streaming) order. Idea: Persist an ordered block list (thinking / reply / tool-call segments in arrival order) during live streaming and restore this same order instead of re-deriving order from the lossy bucketed EditAgentRoundData (thinking -> reply -> toolCalls). Applies to both the StyledText-based and the browser-based conversation rendering.
• Add context menu to conversation widget: Add curated context-menu entries for the browser-based conversation widget (e.g. Copy / Select All / Print / Save-as-HTML). The native browser context menu is currently disabled, because its navigation entries blank the conversation / browser content; re-introduce only safe actions so users regain copy/print/save without exposing refresh/back/forward actions.
• Make test bundles fragments: Make com.microsoft.copilot.eclipse.ui.test bundle (and maybe other test bundles, too) a fragment bundle instead of a separate OSGi bundle (use Fragment-Host entry in MANIFEST.MF). This way we can avoid making production code package-private methods public, just for testing them from a test bundle. The following methods, for example, should all be package-private, not public: in BrowserConversationJavaJsBridge: escapeForJs, insertBlockScript, insertBlockBeforeScript, replaceBlockScript, removeBlockScript, collapseThinkingBlockScript, updateThinkingBodyTextScript, updateThinkingBlockTitleScript and UiUtils.isDark.
• Introduce an image registry, fix Image disposal: Avoid SWT resource leaks during IDE shutdown, properly dispose Image objects, use the plug-in's ImageRegistry for all images (the registry takes care of image disposal).
• React to theme changes (Optional): Listen to theme changes in the OS and in Eclipse IDE and adapt the theme in the browser-based conversation widget (without an IDE restart). Not implemented yet, because switching the appearance theme in Eclipse IDE already pops a dialog recommending a restart (other Eclipse UI parts also don't fully recolor without one), and a restart re-creates the chat view, which picks up the new theme. Covering OS-level theme changes and maybe other cases like switching the background color in Eclipse preferences would make this PR even bigger.
• Further improve streamed copilot response rendering performance (Optional): In case, the rendering appears to be too slow, we could replace reply block and thinking block rendering with incremental streamed-chunk rendering for these blocks. Today the reply and thinking blocks are re-parsed and re-rendered as a whole each time a streamed chunk (often a single word) arrives. Instead, we could improve performance by only re-parsing and re-rendering incomplete chunks in these blocks. Markdown / CommonMark is block-structured and Markdown blocks are delimited by blank lines, so any text above the last blank line (assuming we're not in a source code block) is stable and cannot be restructured by tokens arriving later. We could split the accumulated buffer into a committed prefix (everything before the last blank line, rendered once and never touched) and a live tail (the current, still-growing segment), and only re-render the tail per token; freeze the tail into a committed block when a new blank line arrives. That bounds per-token cost to the current paragraph instead of the whole thinking / reply block. That requires per-block state (committed prefix vs. live tail) and makes the code more complex, especially since we also need to detect (fenced) code blocks in Markdown (and maybe other constructs, too) instead of just blank lines. The change should be applied to both renderers for consistency.